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V ABSTRACT 

Modern piloted flight simulators require de- 
tailed models of many aircraft components, such as 
the airframe, propulsion system, flight deck con- 
trols and instrumentation, as well as motion drive 
and visual display systems. The amount of computing 
power necessary to implement these systems can exceed 
that offered by dedicated mainframe computers. One 
approach to this problem is through the use of dis- 
tributed computing, where parts of the simulation 
are assigned to computing subsystems, such as micro- 
computers. One such subsystem, a real-time, port- 
able, microcomputer-based jet engine simulator, is 
described in this paper. The simulator will be used 
at the NASA Ames Vertical Motion Simulator facility 
to perform calculations previously done on the 
facility's mainframe computer. The mainframe will 
continue to do all other system calculations and 
will interface to the engine simulator through ana- 
log I/O. The engine simulator hardware includes a 
16-bit microcomputer and a floating-point coproces- 
sor. There is an 8 channel analog input board and 
an 8 channel analog output board. A model of a small 
turboshaft engine/control is coded in floating-point 
FORTRAN. The FORTRAN code and a data monitoring 
program run under the control of an assembly language 
real-time executive. The monitoring program allows 
the user to display and/or modify simulator variables 
on-line through a data terminal. A dual disk drive 
system is used for mass storage of programs and data. 
The CP/M-86 operating system provides file management 
and overall system control. The frame time for the 
simulator is 30 milliseconds, which includes all 
analog I/O operations. 


INTRODUCTION 

The accuracy and detail of a simulation is 
determined by the requirements of the simulation 
task, the complexity of the physical system being 
simulated, and the capabilities of the simulation 
computer. Piloted flight simulation is perhaps one 
of the most demanding simulation tasks. A complex 
aircraft system must be represented mathematically, 
and that representation must execute on a computer 
in real-time. The computer must also control various 
flight deck instrumentation, motion drive and visual 
display systems. 

In order to accomplish goals such as the evalu- 
ation of propulsion system and airframe control 
interactions, representative airframe and propulsion 
system models are necessary. However, the detail of 
these models is often constrained by the storage and 
speed limitations of the simulation computer. Ex- 
tensive simplification of some of the aircraft sub- 
system models is then required to allow real-time 
operation. This process not only compromises the 
fidelity of the model, but can be costly and time 


consuming as well. Of course, a faster and more 
powerful simulation computer could be acquired, but 
this Is not always practical. 

One approach to solving this problem is to dis- 
tribute the computational load among many "tightly 
coupled" processors that communicate with each other 
through a specialized network (1). This method is 
currently being investigated, but is not yet mature. 
It does, however, offer the most potential for in- 
creasing computational throughput with current com- 
puter technology. Another, simpler approach is to 
offload part of the computations to a separate com- 
puter system (this system, if necessary, can itself 
consist of several "tightly coupled" computers) which 
is "loosely coupled" to the simulation mainframe. 

The communication between this separate computer 
system and the mainframe could be digital (serial or 
parallel), or through standard A/D and D/A con- 
verters. In either case, the communication overhead 
must be much less than that of the simulation compu- 
tations if any benefit is to be realized. 

The latter approach is the one being taken by 
NASA Lewis Research Center in a distributed process- 
ing experiment to be conducted at the NASA Ames 
Research Center's Vertical Motion Facility (VMS). 

The VMS (2) Is a piloted simulator which, in addi- 
tion to a six-degree-of-freedom type cockpit, is 
also capable of *30-ft of vertical motion. This 
feature is particularly useful for rotorcraft and 
V/STOL applications. Normally, all simulator cal- 
culations for the VMS are done on the facility’s 
mainframe computer. However, for the distributed 
processing experiment, the calculations for the air- 
frame, flight deck instrumentation, motion and visual 
display systems will be performed on the mainframe, 
while the propulsion system calculations will be 
performed on a separate microcomputer system. The 
microcomputer hardware and software, which form a 
stand-alone, portable, real-time simulator, are the 
subject of this paper. 


ENGINE SIMULATOR REQUIREMENTS 

The system to be modeled for this simulation 
experiment was a small turboshaft engine. A typical 
turboshaft engine is shown in figure 1. The turbo- 
shaft propulsion system consists of a compressor, 
combustor, gas generator turbine and a power turbine. 
The engine control consists of a hydromechanlcal 
unit (HMU), that provides basic engine control and 
fuel metering, and an electrical control unit (ECU), 
that trims the HMU to maintain rotor speed and load 
sharing (in the 2-engine helicopter application). 

The ECU also limits the gas generator turbine outlet 
temperature. A more complete description of the 
engine and control system can be found in 
reference 4. 


m 


At NASA Ames Research 
lator must Interface to the 
the hellcoper airframe simulation In a 30 millisecond 
frame time. Selection of the same frame time for 
the engine simulator provides a 3 Hertz bandwidth, 
which was deemed sufficient for the piloted simulator 
application. Using the same frame time also simpli- 
fies the Interfacing of the engine simulator to the 
mainframe. This I/O Interface must be relatively 
simple for low software overhead, but of sufficient 
speed to provide the required data throughput. It 
Is also desirable to have some type of operator 
interface to allow display and/or modification of 
simulation variables. This capability should reside 
on the simulator and consume a small portion of the 
frame time. It Is highly desirable to have the 
engine simulation code written In a high level lan- 
guage and to have sufficient hardware and software 
support for the simulator’s microcomputer to permit 
downloading of the code from a program development 
computer (mainframe) to the simulator. Programming 
of the engine simulation In a high level language 
(i.e., FORTRAN) necessitates the use of real-time 
programming techniques (3). 

The microcomputer hardware itself must meet the 
speed requirements of the particular application. 

It Is also desirable that the hardware be compact 
and easily transported. The technology should be of 
sufficient maturity such that adequate hardware and 
software support is available. This Includes such 
items as a standard bus, 1/0 and peripheral hard- 
ware, and high level language support. 


to one specific hardware and software environment, 
such as the NASA Ames VMS mainframe computer. 


SOFTWARE DESCRIPTION 
Engine and Control Model 

The engine model was derived by applying basic < 
aero thermodynamic principles for each component. t 
Steady state component characteristics were used to 
define the energy and mass transfer across each . 

boundary. Low frequency dynamics, associated with • 
rotor inertias and component heat soaks were re- i 

tained. High frequency volume dynamics were omitted 
since these were considered to be outside the fre- 
quency bandwidth required In piloted simulations. 

Algebraic loops that resulted from omitting high 
frequency dynamics were made to converge by using a 
high gain digital Integrator technique. The result- 
ing dynamic effect Is similar to that resulting from 
application of the conservation equations. Computing 
times were reduced and component performance map 
accuracy was retained by using a curve fitting tech- 
nique similar to regression analysis. The maps were 
curve fit using segmented polynomial functions. 

Since control evaluation Is a prime considera- 
tion In the NASA Ames application, a detailed control 
representation was essential. Accuracy of the con- 
trol model was assured by deriving It directly from 
the control specification diagrams used in the real 
control . 


Center, the engine slmu 
VMS mainframe which runs 
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HARDWARE DESCRIPTION 

The simulator hardware is shown in figure 2. 

It consists of a microcomputer board, a disk drive 
controller board, and analog I/O boards. The boards 
are housed in a 9 slot card cage which has a power 
supply and cooling fans. Presently, 4 of the 9 slots 
are used, leaving 5 slots available for future expan- 
sion. All user interaction is accomplished through 
the attached CRT and keyboard. Two floppy disk 
drives are used for program and data storage. A 
printer is available for hard copies of simulator 
data. 

The microcomputer board is based on the Intel 
8086 microprocessor and the 8087 floating-point co- 
processor. The board has 64K of RAM, parallel and 
serial I/O, programmable timers and an Interrupt 
controller (5). The fast floating-point capability 
provided by the 8087 Is a major reason for its selec- 
tion. Operation of the 8087 is mostly transparent 
to the user, especially if a high level language Is 
used. A FORTRAN compiler and an assembler which 
support both the 8086 and 8087 are available. The 
microcomputer board as well as the other system 
boards are interconnected via Intel's Multibus (5) 
system. Use of the Multibus ensures a wide variety 
of peripheral and other hardware support. 

The analog boards provide 8 channels of analog 
to digital conversion (AOC) and 8 channels of digital 
to analog conversion (DAC). These analog channels 
are used to communicate with the mainframe computer. 
Although noise immunity and accuracy suffer somewhat 
with this approach (as opposed to digital interfac- 
ing) these disadvantages are outweighed by the 
greatly reduced software and hardware overhead. 
Additionally, since many computer systems support 
analog I/O operations, the simulator is not limited 


The resulting analytical model Is a sixteenth 
order model which Includes two real engine states, 
three psuedo engine states and eleven control states. 
The resulting set of differential equations was 
solved as a general Initial and boundary value prob- 
lem using a trapezoidal integration algorithm. The 
function generation and convergence techniques were 
designed specifically to accomplish rapid computa- 
tion and stability. 

The engine model was coded In floating-point 
FORTRAN. The availability of a FORTRAN compiler for 
the 8086-8077 mi crocomputer greatly simplified the 
transporting of the code from the program development 
mainframe to the microcomputer. Only minor changes 
to the original mainframe code were necessary to 
achieve successful compilation on the microcomputer's 
compiler. These changes typically Involved removal 
of I/O statements that were no longer necessary for 
operation on the microcomputer, which had Its own 
library of I/O routines. 

There are several Inputs to the model which. In 
this case, are generated externally on the VMS main- 
frame computer (figure 3). These inputs are routed 
by the mainframe from either the airframe calcula- 
tions or the VMS cockpit mockup. The first Input 
represents a load torque to the engine model. It is 
generated by the airframe simulation and is a result 
of the aerodynamic forces on the rotor blade. 

Another Input, called the load demand spindle (LDS), 
Is a function of the rotor blade collective pitch. 

The collective pitch Is controlled by the hellcoper 
pilot. The power available spindle (PAS) Input sets 
the upper limit on available engine power, and Is 
also set by the pilot. Finally, a power turbine 
reference speed signal, which sets the desired rotor 
speed, is fed to the engine control simulation. 
Environmental conditions are determined from the 
external Inputs of altitude and mach number. In 


2 




ORIGINAL PAGE 13 
OF POOR QUALITY 


response to these Inputs, the engine simulation out- 
puts a generated torque value, as well as outputs 
for cockpit displays such as rotor speed and gas 
turbine Inlet temperature. These Inputs and outputs 
are transferred via the analog Interface of the 
microcomputer-based simulator hardware. 

Assembly Language Executive 

The engine simulator Is an Interrupt-driven 
system. An Interrupt Is generated Internally every 
30 milliseconds to begin the simulator frame. This 
Interrupt is generated by the microcomputer's on- 
board programmable timer. The analog Input board 
used an interrupt to signal the microcomputer that 
converted data Is available. The 8087 also signals 
any floating-point error conditions via Interrupt. 
Finally, a failsafe timer generates an interrupt If 
any external device falls to respond to a data read 
or write request within a specified interval. 

An assembly language executive was developed to 
efficiently handle the response to these interrupts. 
The executive also initializes the simulator system 
before each run. During the simulation frame, after 
all analog data has been read, the FORTRAN engine 
model is called by the executive. After the model 
calculations are completed, the analog output chan- 
nels are updated. The remaining time in the frame 
is spent executing the data monitoring routines. 

These routines continue to execute until the next 
timer interrupt is received to begin the next simu- 
lator frame. 

Assembly language rot tines perform the physical 
analog input and output operations through the DAC 
and ADC hardware. These routines also define the 
logical connection between the hardware DAC or ADC 
channel and a corresponding FORTRAN simulation vari- 
able. The logical connection consists of an address, 
which specifies the FORTRAN variable associated with 
the analog channel, and a scale factor. The scale 
factor is used in the conversion of the FORTRAN 
floating-point representation from/to the integer 
form used by the DAC and ADC hardware. Both the 
address and the scale factor may be modified on- 
line, thus allowing any DAC or ADC channel to be 
reassigned. This feature is particularly useful for 
dynamic debugging of the simulator in a stand-alone 
mode. 

Data Monitoring Software 

The Microcomputer Interactive Data System or 
MINDS is a software package that can be used for 
on-line data display and parameter modification. 

The MINDS software is loaded into the microcomputer 
memory, co-resident with the simulation code and the 
real-time executive. Between the time that the pro- 
cessor has finished computing the simulation and the 
time that it gets the next timer interrupt, the real- 
time executive can call the MINDS software to alien* 
operator interaction with the simulation. This In- 
teraction takes the form of the operator assigning a 
name and data type to certain memory locations. 

This process of assigning attributes to memory loca- 
tions defines MINDS data elements. The operator can 
then display and modify the data elements symboli- 
cally while the simulation Is running. 

In addition, tables of the data elements can be 
defined thereby allowing display of a group of data 
elements simultaneously. The MINDS package contains 
conmands to manipulate the data elements including 
the capability to save data element definitions In a 


disk file so that they can be used at a later time. 
Finally, the MINDS package contains a monitor to 
display and set any group of locations In the micro- 
computer memory referenced by absolute address. The 
monitor also has the ability to set conditional 
breakpoints based on data element values anywhere In 
the executing code. Once the breakpoint has been 
reached, the monitor will collect the values of all 
the microcomputer registers and, optionally, a pre- 
defined data table. This capability facilitated the 
debugging of the real-time simulation. 

CP/M Operating System 

The CP/M operating system Is a general purpose, 
single user operating system marketed by Digital 
Research, Inc. of Pacific Grove, Ca. The operating 
system provides the facilities to do console com- 
munications, program load and unload, disk file 
management and rudimentary memory management. The 
operating system contains three major sections, the 
Command Control Processor (CCP), the Basic Disk 
Operating System (BDOS), and the Basic Input/Output 
System (BIOS). The CCP accepts all commands that 
are typed from the console, interprets them, and 
takes appropriate action. The BDOS contains the 
facilities to read, write and organize files on a 
floppy disk. Finally, the BIOS contains all the 
hardware-dependent Information necessary to allow 
CP/M to operate In a particular environment. 

In the engine simulator application, the CP/M-86 
operating system Is used to load the simulation, 
executive and MINDS software from the floppy disks. 

In addition, the MINDS software uses the operating 
system for disk file management of data element def- 
initions. Further information on CP/M-86 can be 
found in reference 7. 


SOFTWARE DEVELOPMENT CYCLE 

The software development cycle is shown in 
figure 4. The development began with the engine 
model formulation and FORTRAN coding on an IBM 370 
mainframe at NASA Lewis Research Center. Model 
functionality and accuracy were verified on the IBM 
370. At this point, the source code was downloaded 
via a serial link from the IBM 370 to a microcomputer 
development system. The source code was recompiled 
on the development system's resident FORTRAN com- 
piler. The compiler generated native code for the 
8086-8087. The resulting object code was linked 
with the real-time executive and the MINDS object 
code. The final module was then transferred to a 
CP/M-86 compatible disk for conversion to an execut- 
able command file on the engine simulator hardware. 

Timing studies on the hardware verified that 
the 30 ms frame time requirement was met. Next, 
steady state data were collected and compared to 
data obtained from the IBM 370 version of the FORTRAN 
simulation. After the steady state data had been 
verified, transient data were collected. The Inputs 
to the simulator, which would typically be provided 
by the VMS mainframe, were simulated Internally. 

The main control Input, IDS, was stepped and various 
outputs were observed through the DAC channels and a 
strip chart recorder. The step response of the 
microcomputer-based simulator was compared to that 
of the IBM 370 simulation and verified. 

Once operation of the simulator was verified at 
NASA Lewis on a stand-alone basis, steps were initi- 
ated to transport the unit to the VMS facility at 
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NASA Ames. There, It will be interfaced to the 
mainframe computer via the analog I/O. Testing will 
again be performed. Including "open-loop" tests where 
the simulator reads data from the mainframe (which 
executes a resident engine simulation), but the 
mainframe does not receive Input data from the simu- 
lator. The analog outputs will be monitored, how- 
ever, to verify that correct results are being 
generated. The final stage of testing will be com- 
plete when system operation Is verified with the VMS 
being completely dependent on the microcomputer-based 
engine simulator for all engine calculations. 


SIMULATOR OPERATION 

The simulator is Initialized by bootstrapping 
the CP/M-86 operating system. The simulator code 
resides on a disk as a CP/M ".CMD" file which Iden- 
tifies It as an executable command file. It Is In- 
voked by typing the name which precedes the ".CMD" 
suffix. Thus the file "EN6SIM.CM0" Is invoked by 
typing "ENGSIM". The simulator code Is then loaded 
into system memory by CP/M-86. The system starts up 
initially In the MINDS data monitoring software. 

This allows any data element definition files to be 
loaded. After this step, MINDS Is exited by the "." 
command. The Interrupts are then enabled and the 
engine simulation code Is executed. The simulator 
Is Initially in the "IC" or Initial condition mode. 
The simulator mode is selected locally through the 
keyboard or remotely by the mainframe via an analog 
channel. Any of the following modes are available: 
"IC" or initial condition, "RUN" and "HOLD". These 
modes operate similarly to an analog computer. At 
any time, simulation variables may be displayed 
and/or modified since the MINDS software Is con- 
tinually operating during the frame idle time. 

Severe error conditions such as exponent over- 
flow, zero divide and analog output overflow are 
detected by the 8087. The 8087 sends an interrupt 
to the 8086 to notify It of the error condition. 

The 8086 responds by changing the simulator mode to 
"HOLD" and displaying a message on the CRT. The 
message contains Information as to the type of error 
and the location of the error. The operator can 
then attempt to recover from the error and continue 
running or abort the simulation. 


PERFORMANCE 

Timing 

Simulator performance on a stand-alone basis 
has been verified. The simulator timing diagram Is 
shown in figure 5. The overall simulation frame 
time is 30 ms, although the actual computation time 
for the FORTRAN engine simulation is 21 ms. The 
analog I/O operations take a total of 1.4 ms. The 
remaining 7.6 ms is used for operator I/O through 
MINDS. Experience has shown that actually only 4 to 
5 ms Is required for adequate response by the MINDS 
software. This means that at least another 2.6 ms 
is available for additional FORTRAN model computa- 
tions, If needed. Thus for a 30 ms frame time on 
this simulator hardware configuration, 23.6 ms is 
actually available for the FORTRAN engine model cal- 
culations, and 6.4 ms Is required for I/O overhead. 

Accuracy 

Steady state data obtained from the 
microcomputer-based simulator compares almost exactly 


with that obtained from the IBM 370 FORTRAN simula- 
tion. Worst case differences were less than .01 
percent. Since the IBM 370 and the 8087 coprocessor 
handle such things as rounding, floating-point format 
and function evaluation (l.e., square root, etc») 
slightly differently, discrepancies of the type\pb- 
served were expected. 

It should be noted that the 8087 Implements the* 
proposed IEEE floating-point arithmetic standard. 

The IEEE standard Is intended to eliminate most of 
the Inconsistencies In floating-point arithmetic 
among various computer systems. By adhering to this 
standard, discrepancies In floating-point calcula- 
tions among different computers can be minimized. 

The steady state results were also compared to 
those obtained from a more detailed engine model, 
programmed In the continuous system modelling pro- 
gram (CSMP) on the IBM 370. The CSMP model matched 
data from the engine manufacturer's steady state 
cycle deck. The CSW results and the mlcrocomputei- 
based simulator results agreed typically to within 1 
to 3 percent. These differences were attributed to 
the polynomial curve-fit approach used for the com- 
ponent maps on the microcomputer-based simulator. 

The CSW simulation uses table look-up and Interpo- 
lation methods. 

The CSMP model of the engine system Is more 
detailed dynamically, and hence has greater fidelity 
than the model used for the microcomputer-based sim- 
ulator. Transient data from the simulation ade- 
quately matched those from the CSMP model within the 
frequency range of Interest for the piloted simulator 
application. 


CONCLUDING REMARKS 

A real-time, portable, microcomputer-based jet 
engine simulator has been described. The hardware 
and software specifications have been presented. A 
helicopter engine and control model, coded In 
floating-point FORTRAN, has been run on the simulator 
in a 30 ms frame time. The accuracy and frequency 
content of the simulation are of the level required 
for piloted simulations, ’the simulator has been 
evaluated on a stand-alone basis. The engine simu- 
lator will be Integrated into the NASA Ames VMS 
piloted simulator facility where Its performance 
will be evaluated. 

The hardware described in this paper is only 
one approach to constructing a microcomputer-based 
simulator. It Is anticipated that advances In the 
hardware area will make higher performance, lower 
cost systems possible. The availability of fast, 
floating-point hardware has been shown to simplify 
the software development cycle considerably. Real- 
time simulations that were once only achievable 
through the use of Integer, assent ly language tech- 
niques are now possible using high level languages 
and floating-point arithmetic. 
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Figure 1. - Small turboshaft engine. 
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original page m 

0F QUALITY 


ANALOG INPUT 


ANALOG OUTPUT 


TIMER 
INTERRUPT! 


FORTRAN ENGINE MODEL 


j- — 0,4 


ms 


21ms 


l 

l , 
r — 1 ms 
i 


-7.6 ms* 


90 ms 
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